Fix F16 Step Rename: parameter mismatch, closed-.cs staleness, keyword duplication - #37
Merged
Merged
Conversation
…files VS Code seeds the F2 rename dialog for a .feature step with the step's concrete text (real parameter values), since prepareRename's returned range covers the whole line rather than just the abstract expression. HandleRenameAsync validated that concrete text directly against the binding's abstract expression, so the parameter-count check always failed for any parameterized step renamed from the feature side - returning null, which the LSP wrapper silently converts to an empty WorkspaceEdit with no visible error. Add FeatureStepTextBuilder.DeriveExpressionFromEditedText to reconcile the edited concrete text back into an abstract expression (locating the original parameter values in both the old and new text) before validating and propagating the rename to the .cs attribute and other feature usages. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…dy abstract VS's custom "Rename Step" command (RenameStepCommand.cs) seeds its own dialog with the binding's abstract expression regardless of which file the cursor was in, and submits that abstract text verbatim as newName. The previous fix assumed every .feature-triggered rename arrives as concrete text (true for VS Code's native F2, seeded via prepareRename's whole-line range) and unconditionally tried to locate old parameter values inside newName - which fails and wrongly rejects renames that were already in the correct abstract form. Only attempt the concrete-text reconciliation when newName's parameter slot count doesn't already match the live source expression's, so both call patterns work through the same textDocument/rename handler. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
WorkspaceEditApplier.NotifyDidChange only sent textDocument/didChange for .feature files. When a rename rewrote a closed .cs file's binding attribute via File.WriteAllText (ApplyToDisk), the server was never told - its Roslyn binding registry (CSharpBindingDiscoveryService) is only refreshed by didOpen/didChange, and WatchedFilesHandler has no file-system watcher for .cs content changes (only reqnroll.json, .editorconfig, output assemblies, and .cs *deletions*). The renamed feature step showed as unbound until the .cs file was manually opened, triggering didOpen and a live re-parse. Extend the notification to .cs files too - TextDocumentSyncHandler already handles didChange for .cs unconditionally via UpdateFromSourceAsync, with no dependency on a prior didOpen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
HandlePrepareRenameAsync returned a synthetic whole-line range (column 0-200) for .feature steps, so VS Code seeded the rename dialog with the keyword and indentation included (e.g. "\tThen the result should be 120"). Submitting an edited copy of that back as newName, the resulting edit was still applied only at usage.Range - the step-text-only span, excluding the keyword - so the untouched keyword prefix and the keyword baked into the submitted text both ended up in the file: "\tThen \tThen the result should be 120". FindBindingsAtFeatureStep now also reports the matched step's own GherkinRange (excluding keyword/indentation, same span HandleRenameAsync edits at), and prepareRename returns that instead of the synthetic whole-line range. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.featurefile (VS Code's native F2 seeds the dialog with concrete step text, not the abstract binding expression, which previously always failed the parameter-count validation).textDocument/renamehandler: VS Code's concrete-text submission and VS's custom "Rename Step" command's already-abstract submission..csfile's renamed binding attribute leaving the server's registry stale (feature step showed "unbound") until the file was manually reopened.prepareRenamereturning a synthetic whole-line range for.featuresteps, which duplicated the step keyword/indentation when the resulting edit was applied.Test plan
Reqnroll.IdeSupport.LSP.Core.Tests(429 passed)Reqnroll.IdeSupport.LSP.Server.Tests(519 passed, including new regression tests for each fix)Reqnroll.IdeSupport.LSP.Server.Specs(152 passed, including new end-to-end rename scenarios)Reqnroll.IdeSupport.VisualStudio.Wizards.Tests(63 passed)Reqnroll.VisualStudio.Tests(79 passed, including newWorkspaceEditAppliertests).feature) and Visual Studio (custom Rename Step command from both.featureand.cs) by ChrisFollow-up enhancements filed separately: #33, #34, #35, #36
🤖 Generated with Claude Code